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1. Introduction 


This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in TCP/IP-based internets. 
In particular, it defines objects for managing network interfaces 
based on IEEE 802.12. 
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Object Definitions 


Management information is viewed as a collection of managed objects, 
residing in a virtual information store, termed the Management 
Information Base (MIB). Collections of related objects are defined 
in MIB modules. MIB modules are written using a subset of Abstract 
Syntax Notation One (ASN.1) [1] termed the Structure of Management 
Information (SMI) [2]. In particular, each object type is named by 
an OBJECT IDENTIFIER, an administratively assigned name. The object 
type together with an object instance serves to uniquely identify a 
Specific instantiation of the object. For human convenience, we 
often use a textual string, termed the descriptor, to refer to the 
object type. 


Overview 


Instances of these object types represent attributes of an interface 
to an IEEE 802.12 communications medium. At present, IEEE 802.12 
media are identified by one value of the ifType object in the 
Internet-standard MIB: 


ieee80212 (55) 


For this interface, the value of the ifSpecific variable in the MIB- 
II [5] has the OBJECT IDENTIFIER value: 


dot12MIB OBJECT IDENTIFIER ::= { transmission 45 } 


The values for the ifType object are defined by the IANAifType 
textual convention. The Internet Assigned Numbers Authority (IANA) 
is responsible for the assignment of all Internet numbers, including 
new ifType values. Therefore, IANA is responsible for maintaining 
the definition of this textual convention. The current definition of 
the IANAifType textual convention is available from IANA’s World Wide 
Web server at: 


http://www.iana.org/iana/ 


The definitions presented here are based on the IEEE Standard 
802.12-1995, [6] Clause 13 "Layer management functions and services", 
and Annex C "GDMO Specifications for Demand Priority Managed 
Objects".  Implementors of these MIB objects should note that the 
IEEE document explicitly describes (in the form of Pascal pseudocode) 
when, where, and how various MAC attributes are measured. The IEEE 
document also describes the effects of MAC actions that may be 
invoked by manipulating instances of the MIB objects defined here. 
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To the extent that some of the attributes defined in [6] are 
represented by previously defined objects in the Internet-standard 
MIB [5] or in the Evolution of the Interfaces Group of MIB-II [7], 
such attributes are not redundantly represented by objects defined in 
this memo. Among the attributes represented by objects defined in 
other memos are the number of octets transmitted or received on a 
particular interface, the MAC address of an interface, and multicast 
information associated with an interface. 


3.1. MAC Addresses 


All representations of MAC addresses in this MIB module, and in other 
related MIB modules (like RFC 1573), are in "canonical" order defined 
by 802.1a, i.e., as if it were transmitted least significant bit 
first. This is true even if the interface is operating in token ring 
framing mode, which requires MAC addresses to be transmitted most 
significant bit first. 


3.2. Relation to RFC 1213 


This section applies only when this MIB is used in conjunction with 
the "old" (i.e., pre-RFC 1573) interface group. 


The relationship between an IEEE 802.12 interface and an interface in 
the context of the Internet-standard MIB is one-to-one. As such, the 
value of an ifIndex object instance can be directly used to identify 

corresponding instances of the objects defined herein. 


3.3. Relation to RFC 1573 


RFC 1573, the Interface MIB Evolution, requires that any MIB which is 
an adjunct of the Interface MIB, clarify specific areas within the 
Interface MIB. These areas are intentionally left vague in RFC 1573 
to avoid over constraining the MIB, thereby precluding management of 
certain media-types. 


An agent which implements this MIB module must support the 
ifGeneralGroup, ifStackGroup, ifHCPacketGroup, and ifRcvAddressGroup 
of RFC 1573. 


Section 3.3 of RFC 1573 enumerates several areas which a media- 
Specific MIB must clarify. In addition, there are some objects in 
RFC 1573 for which additional clarification of how to apply them to 
an IEEE 802.12 interface would be helpful. Each of these areas is 
addressed in a following subsection. The implementor is referred to 
RFC 1573 in order to understand the general intent of these areas. 
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3.3.1. Layering Model 


For the typical usage of this MIB module, there will be no sub-layers 
"above" or "below" the 802.12 Interface. However, this MIB module 
does not preclude such layering. 


3.3.2. Virtual Circuits 


This medium does not support virtual circuits and this area is not 
applicable to this MIB. 


3.3.3. ifTestTable 


This MIB does not define any tests for media instrumented by this 
MIB. Implementation of the ifTestTable is not required. An 
implementation may optionally implement the ifTestTable to execute 
vendor specific tests. 


3.3.4.  ifRcvAddressTable 


This table contains all IEEE addresses, unicast, multicast, and 
broadcast, for which this interface will receive packets and forward 
them up to a higher layer entity for consumption. In addition, when 
the interface is using 802.5 framing mode, the ifRcvAddressTable will 
contain the functional address mask. 


In the event that the interface is part of a MAC bridge, this table 
does not include unicast addresses which are accepted for possible 
forwarding out some other port. This table is explicitly not 
intended to provide a bridge address filtering mechanism. 


3.3.5. ifPhysAddress 


This object contains the IEEE 802.12 address which is placed in the 
source-address field of any frames that originate at this interface. 
Usually this will be kept in ROM on the interface hardware. Some 
Systems may set this address via software. 


In a system where there are several such addresses the designer has a 
tougher choice. The address chosen should be the one most likely to 
be of use to network management (e.g. the address placed in ARP 
responses for systems which are primarily IP systems). 


If the designer truly can not choose, use of the factory-provided ROM 
address is suggested. 


If the address can not be determined, an octet string of zero length 
should be returned. 
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The address is stored in binary in this object. The address is 
Stored in "canonical" bit order, that is, the Group Bit is positioned 
as the low-order bit of the first octet. Thus, the first byte of a 
multicast address would have the bit 0x01 set. This is true even 
when the interface is using token ring framing mode, which transmits 
addresses high-order bit first. 


3.3.6. Specific Interface MIB Objects 


The following table provides specific implementation guidelines for 
the interface group objects in the conformance groups listed above. 


Object Use for an 802.12 Interface 
ifIndex Each 802.12 interface is represented by an 


ifEntry. Interface tables in this MIB 
module are indexed by ifIndex. 


ifDescr Refer to [7]. 
ifType The IANA reserved value for 802.12 - 55. 
ifMtu The value of ifMtu on an 802.12 interface 


will depend on the type of framing that is 
in use on that interface. Changing the 
doti2DesiredFramingType may have the effect 
of changing ifMtu after the next time that 
the interface trains. When 
doti2CurrentFramingType is equal to 
frameType88023, ifMtu will be equal to 
1500. When doti2CurrentFramingType is 
equal to frameType88025, ifMtu will be 
4464. 


ifSpeed The speed of the interface in bits per 
second. For current 802.12 
implementations, this will be equal to 
100,000,000 (100 million). 


ifPhysAddress See Section 3.3.5. 
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ifAdminStatus 


ifOperStatus 


ifLastChange 


ifInOctets 


ifInUcastPkts 


ifInDiscards 


ifInErrors 


ifInUnknownProtos 


ifOutOctets 


ifOutUcastPkts 


ifOutDiscards 


Flick 
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Write access is not required. Support for 
'testing' is not required. Setting this 
object to 'up' will cause dot12Commands to 
be set to 'open'. Setting this object to 
‘down’ will cause dotl12Commands to be set 
to 'close'. Setting dot12Commands to 
‘open’ will set this object to 'up'. 
Setting doti2Commands to 'close' will set 
this object to 'down'. Setting 
doti2Commands to 'reset' will have no 
effect on this object. 


When doti2Status is equal to 'opened', this 
object will be equal to 'up'. When 
doti2Status is equal to 'closed', 'opening', 
'openFailure' or 'linkFailure', this object 
will be equal to 'down'. Support for 
'testing' is not required, but may be used 
to indicate that a vendor specific test is 
in progress. The value 'dormant' has no 
meaning for an IEEE 802.12 interface. 


Refer to [7]. 

The number of octets in valid MAC frames 
received on this interface, including the 
MAC header and FCS. 

Refer to [7]. 

Refer to [7]. 

The sum for this interface of 
dot121nIPMErrors, 
doti2InOversizeFrameErrors, 
doti2InDataErrors, and any additional 
internal errors that may occur in an 
implementation. 

Refer to [7]. 

The number of octets transmitted in MAC 
frames on this interface, including the MAC 
header and FCS. 

Refer to [7]. 


Refer to [7]. 
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ifOutErrors 


ifName 


ifInMulticastPkts 


ifInBroadcastPkts 


ifOutMulticastPkts 


ifOutBroadcastPkts 
ifHCInOctets 
ifHCOutOctets 


ifHC*Pkts 


ifLinkUpDownTrapEnable 


ifHighSpeed 


ifPromiscuousMode 
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The number of implementation-specific 
internal transmit errors on this interface. 


Locally-significant textual name for the 
interface (e.g. vg0). 


Refer to [7]. When dot12CurrentFramingType 
is frameType88025, this count includes 
packets addressed to functional addresses. 


Refer to [7]. 


Refer to [7]. When dot12CurrentFramingType 
is frameType88025, this count includes 
packets addressed to functional addresses. 


Refer to [7]. 
64-bit version of ifInOctets. 
64-bit version of ifOutOctets 


Not required for 100 MBit interfaces. 
Future IEEE 802.12 interfaces which operate 
at higher speeds may require implementation 
of these counters, but such interfaces are 
beyond the scope of this memo. 


Refer to [7]. Default is 'enabled'. 


The speed of the interface in millions of 
bits per second. For current 802.12 
implementations, this will be equal to 100. 


Reflects whether the interface has 
successfully trained and is currently 
operating in promiscuous mode. 
dotl2DesiredPromiscStatus is used to select 
the promiscuous mode to be requested in the 
next training attempt. Setting 
ifPromiscuousMode will update 
doti2DesiredPromiscStatus and cause the 
interface to attempt to retrain using the 
new promiscuous mode. After the interface 
has retrained, ifPromiscuousMode will 
reflect the mode that is in use, not the 
mode that was requested. 
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ifConnectorPresent This will normally be 'true'. 


ifStackHigherLayer Refer to section 3.3.1 
ifStackLowerLayer 
ifStackStatus 


ifRcvAddressAddress Refer to section 3.3.4. 
ifRcvAddressStatus 
ifRcvAddressType 


3.4. Relation to RFC 1643, RFC 1650, and RFC 1748 


An IEEE 802.12 interface can be configured to operate in either 
ethernet or token ring framing mode. An IEEE 802.12 interface uses 
the frame format for the configured framing mode, but does not use 
the media access protocol for ethernet or token ring. Instead, IEEE 
802.12 defines its own media access protocol, the Demand Priority 
Access Method (DPAM). 


There are existing standards-track MIB modules for instrumenting 
ethernet-like interfaces and token ring interfaces. At the time of 
this writing, they are: STD 50, RFC 1643, "Definitions of Managed 
Objects for Ethernet-like Interface Types" [8]; RFC 1650, 
"Definitions of Managed Objects for Ethernet-like Interface Types 
using SMIv2" [9]; and RFC 1748, "IEEE 802.5 MIB using SMIv2" [10]. 
These MIB modules are designed to instrument the media access 
protocol for these respective technologies. Since IEEE 802.12 
interfaces do not implement either of these media access protocols, 
an agent should not implement RFC 1643, RFC 1650, or RFC 1748 for 
IEEE 802.12 interfaces. 


3.5. Relation to RFC 1749 


When an IEEE 802.12 interface is operating in token ring framing 
mode, and the end node supports token ring source routing, the agent 
should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB 
[11] for those interfaces. 
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6. Master Mode Operation 


In an IEEE 802.12 network, "master" devices act as network 
controllers to decide when to grant requesting end-nodes permission 
to transmit. These master devices may be repeaters, or other active 
controller devices such as switches. 


Devices which do not act as network controllers, such as end-nodes or 
passive switches, are considered to be operating in "slave" mode. 


The dotli2ControlMode object indicates if the interface is operating 
in master mode or slave mode. 


7. Normal and High Priority Counters 


The IEEE 802.12 interface MIB does not provide normal priority 
transmit counters. Standardization of normal priority transmit 
counters could not be justified -- ifOutUcastPkts, 
ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets, 
doti20utHighPriorityFrames, and doti20utHighPriorityOctets should 
suffice. More precisely, the number of normal priority frames 
transmitted can be calculated as: 


outNormPriorityFrames - ifOutUcastPkts + 
ifOutMulticastPkts + 
ifOutBroadcastPkts m 


doti20utHighPriorityFrames 


The number of normal priority octets transmitted can be calculated 
as: 


outNormPriorityOctets - ifOutOctets E 
dot120utHighPriorityOctets 


On the other hand, normal priority receive counters are provided. 
The main reason for this is that the normal priority and high 
priority counters include errored frames, whereas the ifIn*Pkts and 
ifInOctets do not include errored frames. dot12InNormPriorityFrames 
could be calculated, but the calculation is tedious: 


inNormPriorityFrames = ifInUcastPkts 
iflnMulticastPkts 
iflnBroadcastPkts 
doti21nNullAddressedFrames 
ifInErrors 
ifInDiscards 
ifInUnknownProtos 
dotl21nHighPriorityFrames 


++++++ 
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doti2InNormPriorityOctets includes octets in unreadable frames, which 
is not available elsewhere. The number of octets in unreadable 
frames can be calculated as: 


octetsInUnreadableFrames = doti21InNormPriorityOctets + 
dotli21nHighPriorityOctets - 
ifInOctets 


Also, the total traffic at this interface can be calculated as: 


traffic = dotl21nNormPriorityOctets + 
dot1i2InHighPriorityOctets + 
ifOutOctets 


In other words, the normal priority receive counters were deemed 
useful, whereas the normal priority transmit counters can be easily 
calculated from other available counters. 


3.8. IEEE 802.12 Training Frames 


Training frames are special MAC frames that are used only during link 
initialization. Training frames are initially constructed by the 
device at the lower end of a link, which is the slave mode device for 
the link. The training frame format is as follows: 


4+----4----+4------------ 4R-------------- R---------- 4+----- + 
| DA | SA | Req Config | Allow Config | Data | FCS 


DA = destination address (six octets) 

SA = source address (six octets) 

Req Config = requested configuration (2 octets) 
Allow Config = allowed configuration (2 octets) 
Data = data (594 to 675 octets) 

FCS = frame check sequence (4 octets) 


Training frames are always sent with a null destination address. To 
pass training, an end node must use its source address in the source 
address field of the training frame. A repeater may use a non-null 
Source address if it has one, or it may use a null source address. 
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The requested configuration field allows the slave mode device to 
inform the master mode device about itself and to request 
configuration options. The training response frame from the master 
mode device contains the slave mode device's requested configuration 
from the training request frame. The currently defined format of the 
requested configuration field as defined in the IEEE Standard 
802.12-1995 standard is shown below. Please refer to the most 
current version of the IEEE document for a more up to date 
description of this field. In particular, the reserved bits may be 
used in later versions of the standard. 


First Octet: Second Octet: 


T 6.5 4.3 21-0 76543210 


vvv: The version of the 802.12 training protocol with which 


the training initiator is compliant. The current version 
is 100. 
r: Reserved bits (set to zero) 


FF: 00 = frameType88023 

01 = frameType88025 

10 = reserved 

11 - frameTypeEither 
PP: 00 = singleAddressMode 


01 = promiscuousMode 
10 = reserved 
11 = reserved 
R: 0 = the training initiator is an end node 
1 = the training initiator is a repeater 


The allowed configuration field allows the master mode device to 
respond with the allowed configuration. The slave mode device sets 
the contents of this field to all zero bits. The master mode device 
sets the allowed configuration field as follows: 


First Octet: Second Octet: 


7. @ 04 23> 2 1 0 76543210 


vvv: The version of the 802.12 training protocol with which 
the training responder is compliant. The current version 
is 100. 
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Ds 0 = No duplicate address has been detected. 
1 = Duplicate address has been detected 
Cs 0 = The requested configuration is compatible with the 
network. 
1 = The requested configuration is not compatible with 


the network. In this case, the FF, PP, and R bits 
indicate the configuration that would be allowed. 


N: 0 = Access will be allowed, providing the configuration 
is compatible (C = 0). 
1 = Access is not granted because of security 
restrictions 
Es Reserved bits (set to zero) 
FF: 00 = frameType88023 will be used 
01 = frameType88025 will be used 
10 = reserved 
11 = reserved 
PP: 00 = singleAddressMode 
01 = promiscuousMode 
10 = reserved 
11 = reserved 
R: 0 = Requested access as an end node is allowed 
1 = Requested access as a repeater is allowed 


Again, note that the most recent version of the IEEE 802.12 standard 
should be consulted for the most up to date definition of the 
requested configuration and allowed configuration fields. 


The data field contains between 594 and 675 octets and is filled in 
by the training initiator. The first 55 octets may be used for 
vendor specific protocol information. The remaining octets are all 
zeros. The length of the training frame combined with the 
requirement that 24 consecutive training frames be received without 
error to complete training ensures that marginal links will not 
complete training. 


3.9. Mapping of IEEE 802.12 Managed Objects 


The following table lists all the managed objects defined for 
oEndNode in the IEEE 802.12 Standard, and the corresponding SNMP 


objects. 

TEEE 802.12 Managed Object Corresponding SNMP Object 

oEndNode 
.aBroadcastFramesReceived IF-MIB - ifInBroadcastPkts 
.aBroadcastFramesTransmitted IF-MIB - ifOutBroadcastPkts 
.aDataErrorFramesReceived doti21InDataErrors 
.aDesiredFramingType dot12DesiredFramingType 
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.aDesiredPromiscuousStatus 
.aFramesTransmitted 


.aFramingCapability 
.aFunctionalAddresses 
.aHighPriorityFramesReceived 
.aHighPriorityFramesTransmitted 
.aHighPriorityOctetsReceived 


.aHighPriorityOctetsTransmitted 


.aIPMFramesReceived 
.aLastTrainingConfig 
.aMACID 
aMACStatus 
.aMACVersion 
aMediaType 


MulticastFramesReceived 
MulticastFramesTransmitted 
MulticastReceiveStatus 
NormalPriorityFramesReceived 
NormalPriorityOctetsReceived 


ooo ow 


.aNullAddressedFramesReceived 
.aOctetsTransmitted 


.aOversizeFramesReceived 
.aReadableFramesReceived 


.aReadableOctetsReceived 


.aReadMulticastList 
.aReadWriteMACAddress 
.aTransitionsIntoTraining 
.acAddGroupAddress 
.acClose 
.acDeleteGroupAddress 
.acExecuteSelftest 
.acInitializeMAC 

.acOpen 


Standards Track 


IEEE 802.12 Interface MIB 


October 1996 


doti2DesiredPromiscStatus 
IF-MIB - ifOutUCastPkts + 
ifOutMulticastPkts - 
ifOutBroadcastPkts 
dotli2FramingCapability 
IF-MIB - ifRcvAddressTable 
dotli21nHighPriorityFrames 
doti20utHighPriorityFrames 
doti21nHighPriorityOctets or 
dotl121nHCHighPriorityOctets 
doti20utHighPriorityOctets or 
dot120utHCHighPriorityOctets 
dotl121nIPMErrors 
doti2LastTrainingConfig 
IF-MIB - ifIndex 
doti2Status 
dotli2TrainingVersion 
«not yet mapped» 
Tranceiver MIB issue 
IF-MIB - ifInMulticastPkts 
IF-MIB - ifOutMulticastPkts 
IF-MIB - ifRcvAddressTable 
doti21nNormPriorityFrames 
doti21nNormPriorityOctets or 
dotl121nHCNormPriorityOctets 
dot12InNullAddressedFrames 
IF-MIB - ifOutOctets or 
ifHCOutOctets 
doti21InOversizeFrameErrors 
IF-MIB - ifInUcastPkts + 
iflnMulticastPkts + 
iflnBroadcastPkts 
IF-MIB - ifInOctets or 
ifHCInOctets 
IF-MIB - ifRcvAddressTable 
IF-MIB - ifPhysAddress 
doti2TransitionIntoTrainings 
IF-MIB - ifRcvAddressTable 
doti12Commands: 'close"' 
IF-MIB - ifRcvAddressTable 
IF-MIB - ifAdminStatus 
doti12Commands: 'reset' 
doti2Commands: ’ open’ 
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4. Definitions 
DOT12-IF-MIB DEFINITIONS ::= BEGIN 
IMPORTS 
transmission, Counter32, Counter64, OBJECT-TYPE, 


MODULE-IDENTITY 


FROM SNMPv2-SMI 


MODULE-COMPLIANCE, 


OBJECT-GROUP 


FROM SNMPv2-CONF 


ifIndex 
FROM IF-MIB; 


dot12MIB MODULE-IDENTITY 


LAST-UPDATED 


"96022204522" 


-- February 22, 1996 


ORGANIZATION "IETF 100VG-AnyLAN MIB Working Group" 


CONTACT-INFO 


bj John Flick 

Postal: Hewlett Packard Company 
8000 Foothills Blvd. M/S 5556 
Roseville, CA 95747-5556 

Tel: +1 916 785 4018 

Fax +1 916 785 3583 

E-mail: johnf@hprnd.rose.hp.com" 

DESCRIPTION 


"This MIB module describes objects for 
managing IEEE 802.12 interfaces." 

:= { transmission 45 } 

OBJECT IDENTIFIER ::= 


dot12MIBObjects { dot12MIB 1 } 


doti2ConfigTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Dot12ConfigEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"Configuration information for a collection of 
802.12 interfaces attached to a particular 
system." 

::= ( dot1l2MIBObjects 1 } 


doti2ConfigEntry OBJECT-TYPE 
SYNTAX Dot12ConfigEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
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"Configuration for a particular interface to an 
802.12 medium." 

INDEX { ifIndex } 

::= ( dotl12ConfigTable 1 } 


Dot12ConfigEntry ::= 
SEQUENCE { 
doti2CurrentFramingType INTEGER, 
doti2DesiredFramingType INTEGER, 
dotl2FramingCapability INTEGER, 
dot12DesiredPromiscStatus INTEGER, 
dotli2TrainingVersion INTEGER, 
doti2LastTrainingConfig OCTET STRING, 
dot12Commands INTEGER, 
doti2Status INTEGER, 
dot12ControlMode INTEGER 


} 


doti2CurrentFramingType OBJECT-TYPE 
SYNTAX INTEGER { 
frameType88023 (1), 
frameType88025 (2), 
frameTypeUnknown (3) 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"When dot12DesiredFramingType is one of 
'frameType88023' or 'frameType88025', this is the 
type of framing asserted by the interface. 


When doti2DesiredFramingType is 'frameTypeEither', 
doti2CurrentFramingType shall be one of 
'frameType88023' or 'frameType88025' when the 
doti2Status is 'opened'. When the dot12Status is 
anything other than ’opened’, 
doti2CurrentFramingType shall take the value of 
' £rameTypeUnknown' ." 

::= ( dotl2ConfigEntry 1 } 


dot12DesiredFramingType OBJECT-TYPE 
SYNTAX INTEGER { 

frameType88023 (1 

frameType88025 (2 

frameTypeEither( 


); 
); 

3) 
} 


MAX-ACCESS read-write 
STATUS current 
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DESCRIPTION 
"The type of framing which will be requested by 
the interface during the next interface MAC 
initialization or open action. 


In master mode, this is the framing mode which 
will be granted by the interface. Note that 
for a master mode interface, this object must be 
equal to 'frameType88023' or 'frameType88025', 
since a master mode interface cannot grant 
'frameTypeEither'." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aDesiredFramingType." 

:= ( dotl2ConfigEntry 2 ] 


doti2FramingCapability OBJECT-TYPE 


SYNTAX INTEGER { 
frameType88023(1), 
frameType88025(2), 
frameTypeEither (3) 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"The type of framing this interface is capable of 
supporting." 
REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aFramingCapability." 


::= ( dotl2ConfigEntry 3 } 


dot1l2DesiredPromiscStatus OBJECT-TYPE 
SYNTAX INTEGER { 
singleAddressMode (1), 
promiscuousMode (2) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"This object is used to select the promiscuous 
mode that this interface will request in the next 
training packet issued on this interface. 
Whether the repeater grants the requested mode 
must be verified by examining the state of the PP 
bits in the corresponding instance of 
doti2LastTrainingConfig. 
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In master mode, this object controls whether or 
not promiscuous mode will be granted by the 
interface when requested by the lower level 
device. 


Note that this object indicates the desired mode 
for the next time the interface trains. The 
currently active mode will be reflected in 
dotli2LastTrainingConfig and in ifPromiscuousMode." 
REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aDesiredPromiscuousStatus." 
::= ( dotl2ConfigEntry 4 } 


doti2TrainingVersion OBJECT-TYPE 

SYNTAX INTEGER (0..7) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"The value that will be used in the version bits 
(vvv bits) in training frames on this interface. 
This is the highest version number supported by 
this MAC." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aMACVersion." 

::— ( dotl12ConfigEntry 5 } 


doti2LastTrainingConfig OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE(2)) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This 16 bit field contains the configuration 
bits from the most recent error-free training 
frame received during training on this interface. 
Training request frames are received when in 
master mode, while training response frames are 
received in slave mode. On master mode interfaces, 
this object contains the contents of the 
requested configuration field of the most recent 
training request frame. On slave mode interfaces, 
this object contains the contents of the allowed 
configuration field of the most recent training 
response frame. The format of the current version 
of this field is described in section 3.8. Please 
refer to the most recent version of the IEEE 
802.12 standard for the most up-to-date definition 
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of the format of this object." 
REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aLastTrainingConfig." 
::— ( dotl12ConfigEntry 6 } 


doti2Commands OBJECT-TYPE 
SYNTAX INTEGER { 
noOp(1) 

open (2), 

reset(3), 

close(4) 


r 


} 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 
"If the current value of dot12Status is 'closed', 
setting the value of this object to 'open' will 
change the corresponding instance of MIB-II's 
ifAdminStatus to 'up', cause this interface to 
enter the 'opening' state, and will cause training 
to be initiated on this interface. The progress 
and success of the open is given by the values of 
the doti2Status object. Setting this object to 
'open' when doti2Status has a value other than 
'closed' has no effect. 


Setting the corresponding instance of ifAdminStatus 
to 'up' when the current value of dot12Status is 
'closed' will have the same effect as setting this 
object to 'open'. Setting ifAdminStatus to 'up"' 
when dot12Status has a value other than ’closed’ 
has no effect. 


Setting the value of this object to 'close' will 
move this interface into the 'closed' state and 
cause all transmit and receive actions to stop. 
This object will then have to be set to 'open' in 
order to reinitiate training. 


Setting the corresponding instance of ifAdminStatus 
to 'down' will have the same effect as setting this 
object to 'close'. 


Setting the value of this object to 'reset' when 
the current value of dot12Status has a value other 
than 'closed' will reset the interface. On a 
reset, all MIB counters should retain their values. 
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This will cause the MAC to initiate an 
acInitializeMAC action as specified in IEEE 802.12. 
This will cause training to be reinitiated on this 
interface. Setting this object to 'reset' when 
doti2Status has a value of 'closed' has no effect. 
Setting this object to 'reset' has no effect on the 
corresponding instance of ifAdminStatus. 


Setting the value of this object to 'noOp' has no 
effect. 


When read, this object will always have a value 
of 'noOp'." 


REFERENCE 


"IEEE Standard 802.12-1995, 13.2.5.2.2, 
acOpen, acClose, acInitializeMAC. 

Also, RFC1231 IEEE802.5 Token Ring MIB, 
dot5Commands." 


( doti2ConfigEntry 7 } 


doti2Status OBJECT-TYPE 


INTEGER { 
opened(1), 
closed(2), 
opening(3), 
openFailure(5), 
linkFailure (6) 

} 


MAX-ACCESS read-only 


current 


DESCRIPTION 


"The current interface status with respect to 
training. One of the following values: 


opened - Training has completed 
successfully. 

closed - MAC has been disabled by 
setting dot12Commands to 
'elose*t. 

opening - MAC is in training. Training 


signals have been received. 
openFailure - Passed 24 error-free packets, 
but there is a problem, noted 
in the training configuration 
bits (dotli2LastTrainingConfig). 


linkFailure - Training signals not received, 
or could not pass 24 error-free 
packets. 
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Whenever the dotl2Commands object is set to 
'close' or ifAdminStatus is set to 'down', the MAC 
will go silent, doti2Status will be 'closed', and 
ifOperStatus will be 'down'. 


When the value of this object is equal to ’closed’ 
and the dot12Commands object is set to 'open' or 
the ifAdminStatus object is set to 'up', training 
will be initiated on this interface. When the 
value of this object is not equal to 'closed' and 
the doti2Commands object is set to 'reset', 
training will be reinitiated on this interface. 
Note that sets of some other objects (e.g. 
doti2ControlMode) or external events (e.g. MAC 
protocol violations) may also cause training to be 
reinitiated on this interface. 


When training is initiated or reinitiated on an 
interface, the end node will send Training Up to 
the master and initially go to the ’linkFailure’ 
state and ifOperStatus will go to 'down'. 

When the master sends back Training Down, 
doti2Status will change to the 'opening' state, 
and training packets will be transferred. 


After all of the training packets have been 
passed, dotl12Status will change to ’linkFailure’ 
if 24 consecutive error-free packets were not 
passed, 'opened' if 24 consecutive error-free 
packets were passed and the training 
configuration bits were OK, or 'openFailure' if 
there were 24 consecutive error-free packets, but 
there was a problem with the training 
configuration bits. 


When in the 'openFailure' state, the 
dotli2LastTrainingConfig object will contain the 
configuration bits from the last training 
packet which can be examined to determine the 
exact reason for the training configuration 
failure. 


If training did not succeed (doti2Status is 
'linkFailure' or 'openFailure), the entire 
process will be restarted after 

MAC Retraining Delay Timer seconds. 


If training does succeed (dot12Status changes to 
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'opened'), ifOperStatus will change to 'up'. If 
training does not succeed (dot12Status changes to 
'linkFailure' or 'openFailure'), ifOperStatus will 
remain 'down'." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aMACStatus." 

:= { dotl2ConfigEntry 8 } 


doti2ControlMode OBJECT-TYPE 
SYNTAX INTEGER { 
masterMode (1), 
slaveMode (2), 
learn(3) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"This object is used to configure and report 
whether or not this interface is operating in 
master mode. In a Demand Priority network, end 
node interfaces typically operate in slave mode, 
while switch interfaces may control the Demand 
Priority protocol and operate in master mode. 


This object may be implemented as a read-only 
object by those agents and interfaces that do not 
implement software control of master mode. In 
particular, interfaces that cannot operate in 
master mode, and interfaces on which master mode 
is controlled by a pushbutton on the device, 
should implement this object read-only. 


Some interfaces do not require network management 
configuration of this feature and can autosense 
whether to use master mode or slave mode. The 
value 'learn' is used for that purpose. While 
autosense is taking place, the value 'learn' is 
returned. 


A network management operation which modifies the 
value of doti12ControlMode causes the interface 
to retrain." 

:= { dotl2ConfigEntry 9 } 


doti2StatTable OBJECT-TYPE 
SYNTAX SEQUENCE OF Dot12StatEntry 
MAX-ACCESS not-accessible 
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STATUS current 

DESCRIPTION 
"Statistics for a collection of 802.12 interfaces 
attached to a particular system." 

::— ( dotl12MIBObjects 2 } 


doti2StatEntry OBJECT-TYPE 

SYNTAX Doti2StatEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"Statistics for a particular interface to an 
802.12 medium. The receive statistics in this 
table apply only to packets received by this 
station (i.e., packets whose destination address 
is either the local station address, the 
broadcast address, or a multicast address that 
this station is receiving, unless the station is 
in promiscuous mode)." 

INDEX { ifIndex } 

::= { dot1l2StatTable 1 } 


Doti2StatEntry ::= 
SEQUENCE { 
dotli21nHighPriorityFrames Counter32, 
doti2InHighPriorityOctets Counter32, 
doti2InNormPriorityFrames Counter32, 
doti21InNormPriorityOctets Counter32, 
dot121nIPMErrors Counter32, 
doti2InOversizeFrameErrors Counter32, 
doti2InDataErrors Counter32, 
dot12InNullAddressedFrames Counter32, 
dot120utHighPriorityFrames Counter32, 
dot120utHighPriorityOctets Counter32, 
dotli2TransitionIntoTrainings Counter32, 
dotl12HCInHighPriorityOctets Counter64, 
dotl12HCInNormPriorityOctets Counter64, 
doti2HCOutHighPriorityOctets Counter64 


} 


dot1l2InHighPriorityFrames OBJECT-TYPE 

SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of high priority frames 
that have been received on this interface. 
Includes both good and bad high priority frames, 
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as well as high priority training frames. Does 
not include normal priority frames which were 
priority promoted." 
REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aHighPriorityFramesReceived." 
:= ( dotl2StatEntry 1 } 


dotl21nHighPriorityOctets OBJECT-TYPE 

SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of the number of octets 
contained in high priority frames that have been 
received on this interface. This counter is 
incremented by OctetCount for each frame received 
on this interface which is counted by 
dotli21nHighPriorityFrames. 


Note that this counter will roll over very 
quickly. It is provided for backward 
compatibility for Network Management protocols 
that do not support 64 bit counters (e.g. SNMP 
version 1)." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aHighPriorityOctetsReceived." 

:= ( dotl2StatEntry 2 ] 


dotl21nNormPriorityFrames OBJECT-TYPE 

SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of normal priority frames 
that have been received on this interface. 
Includes both good and bad normal priority 
frames, as well as normal priority training 
frames and normal priority frames which were 
priority promoted." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aNormalPriorityFramesReceived." 

:= ( doti12StatEntry 3 } 


dotli21nNormPriorityOctets OBJECT-TYPE 
SYNTAX Counter32 
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MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of the number of octets 
contained in normal priority frames that have 
been received on this interface. This counter is 
incremented by OctetCount for each frame received 
on this interface which is counted by 
dotli21nNormPriorityFrames. 


Note that this counter will roll over very 
quickly. It is provided for backward 
compatibility for Network Management protocols 
that do not support 64 bit counters (e.g. SNMP 
version 1)." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aNormalPriorityOctetsReceived." 

::— ( doti2StatEntry 4 } 


dotl21I1nIPMErrors OBJECT-TYPE 

SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of the number of frames 
that have been received on this interface with an 
invalid packet marker and no PMI errors. A 
repeater will write an invalid packet marker to 
the end of a frame containing errors as it is 
forwarded through the repeater to the other 
ports. This counter is incremented by one for 
each frame received on this interface which has 
had an invalid packet marker added to the end of 
the frame." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
alPMFramesReceived." 

::— ( doti2StatEntry 5 } 


doti21nOversizeFrameErrors OBJECT-TYPE 


SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of oversize frames 
received on this interface. This counter is 


incremented by one for each frame received on 
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this interface whose OctetCount is larger than 
the maximum legal frame size. The frame size 
which causes this counter to increment is 
dependent on the current framing type." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aOversizeFramesReceived." 

:= ( doti12StatEntry 6 } 


doti21InDataErrors OBJECT-TYPE 


SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of errored frames 
received on this interface. This counter is 


incremented by one for each frame received on 
this interface with any of the following errors: 
bad FCS (with no IPM), PMI errors (excluding 
frames with an IPM as the only PMI error), 
undersize, bad start of frame delimiter, or bad 
end of packet marker. Does not include frames 
counted by dotl2InIPMErrors, 
doti2InNullAddressedFrames, or 
doti2InOversizeFrameErrors. 


This counter indicates problems with the cable 
directly attached to this interface, while 
dotl2InIPMErrors indicates problems with remote 
cables." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aDataErrorFramesReceived." 

::— ( doti2StatEntry 7 } 


doti21nNullAddressedFrames OBJECT-TYPE 


SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of null addressed frames 
received on this interface. This counter is 


incremented by one for each frame received on 
this interface with a destination MAC address 
consisting of all zero bits. Both void and 

training frames are included in this counter. 


Note that since this station would normally not 
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receive null addressed frames, this counter is 
only incremented when this station is operating 
in promiscuous mode or in training." 
REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aNullAddressedFramesReceived." 
:= ( doti12StatEntry 8 } 


doti20utHighPriorityFrames OBJECT-TYPE 

SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This counter is incremented by one for each high 
priority frame successfully transmitted out this 
interface." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aHighPriorityFramesTransmitted." 

::— ( doti2StatEntry 9 } 


doti20utHighPriorityOctets OBJECT-TYPE 
SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"This counter is incremented by OctetCount for 
each frame counted by dot120utHighPriorityFrames. 


Note that this counter will roll over very 
quickly. It is provided for backward 
compatibility for Network Management protocols 
that do not support 64 bit counters (e.g. SNMP 
version 1)." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aHighPriorityOctetsTransmitted." 

::— ( dot12StatEntry 10 } 


dotli2TransitionIntoTrainings OBJECT-TYPE 

SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of the number of times 
this interface has entered the training state. 
This counter is incremented by one each time 
doti2Status transitions to 'linkFailure' from any 
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state other than 'opening' or 'openFailure'. 
REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aTransitionsIntoTraining." 
::= ( dotl2StatEntry 11 } 


dotl12HCInHighPriorityOctets OBJECT-TYPE 

SYNTAX Counter64 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of the number of octets 
contained in high priority frames that have been 
received on this interface. This counter is 
incremented by OctetCount for each frame received 
on this interface which is counted by 
dotl21nHighPriorityFrames. 


This counter is a 64 bit version of 
doti2InHighPriorityOctets. It should be used by 
Network Management protocols which support 64 bit 
counters (e.g. SNMPv2)." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aHighPriorityOctetsReceived." 

::= { dotl2StatEntry 12 } 


dotl12HCInNormPriorityOctets OBJECT-TYPE 

SYNTAX Counter64 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This object is a count of the number of octets 
contained in normal priority frames that have 
been received on this interface. This counter is 
incremented by OctetCount for each frame received 
on this interface which is counted by 
dotli21nNormPriorityFrames. 


This counter is a 64 bit version of 
doti2InNormPriorityOctets. It should be used by 
Network Management protocols which support 64 bit 
counters (e.g. SNMPv2)." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aNormalPriorityOctetsReceived." 

::— ( dot1l2StatEntry 13 } 
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dotli2HCOutHighPriorityOctets OBJECT-TYPE 
SYNTAX Counter64 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"This counter is incremented by OctetCount for 
each frame counted by dot120utHighPriorityFrames. 


This counter is a 64 bit version of 
doti2O0utHighPriorityOctets. It should be used by 
Network Management protocols which support 64 bit 
counters (e.g. SNMPv2)." 

REFERENCE 
"IEEE Standard 802.12-1995, 13.2.5.2.1, 
aHighPriorityOctetsTransmitted." 

::= ( dotl2StatEntry 14 } 


-—— conformance information 


doti2Conformance OBJECT IDENTIFIER { dot12MIB 2 } 


doti2Compliances OBJECT IDENTIFIER ::= { doti2Conformance 1 } 
doti2Groups OBJECT IDENTIFIER ::= { dotl2Conformance 2 } 


-- compliance statements 


doti2Compliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 
"The compliance statement for managed network 
entities that have 802.12 interfaces." 


MODULE  -- this module 
MANDATORY-GROUPS ( dot12ConfigGroup, dotl2StatsGroup } 


OBJECT dot12DesiredFramingType 
MIN-ACCESS read-only 
DESCRIPTION 


"Write access to this object is not required." 


OBJECT dot12DesiredPromiscStatus 
MIN-ACCESS read-only 
DESCRIPTION 


"Write access to this object is not required." 


OBJECT dot12Commands 
MIN-ACCESS read-only 
DESCRIPTION 
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"Write access to this object is not required." 


OBJECT dot12ControlMode 
MIN-ACCESS read-only 
DESCRIPTION 


"Write access to this object is not required." 
:= { dotl2Compliances 1 } 


-—- units of conformance 


doti2ConfigGroup OBJECT-GROUP 
OBJECTS { doti2DesiredFramingType, 
doti2FramingCapability, 
doti2DesiredPromiscStatus, 
doti2TrainingVersion, 
doti2LastTrainingConfig, 
doti2Commands, doti12Status, 
doti2CurrentFramingType, 
doti2ControlMode } 
STATUS current 
DESCRIPTION 
"A collection of objects for managing the status 
and configuration of IEEE 802.12 interfaces." 
::= ( dotl12Groups 1 } 


doti2StatsGroup OBJECT-GROUP 

OBJECTS { doti2InHighPriorityFrames, 
dotli21nHighPriorityOctets, 
doti21nNormPriorityFrames, 
doti21nNormPriorityOctets, 
dot121nIPMErrors, 
doti21InOversizeFrameErrors, 
doti2InDataErrors, 
doti21nNullAddressedFrames, 
doti20utHighPriorityFrames, 
doti20utHighPriorityOctets, 
dotli2TransitionIntoTrainings, 
dotl12HCInHighPriorityOctets, 
dotl12HCInNormPriorityOctets, 
doti2HCOutHighPriorityOctets } 

STATUS current 

DESCRIPTION 

"A collection of objects providing statistics for 
IEEE 802.12 interfaces." 
:= ( dotl2Groups 2 } 


END 
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